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(54) Data processing method 

(57) Even if an object enters a waiting state due to 
some problem while future-based message passing is 
being performed, the object is able to exit from the wait- 
ing state without needing to execute time-out process- 
ing. When sending a message from a client object to a 
server object, a data area is reserved. If processing ex- 
ecuted by the server object is correctly completed, the 
data indicating the processing result is stored in the 



above-described data area. If processing executed by 
the server object is not correctly completed, the data in- 
dicating the status of the server object is stored in the 
above-described data area. By reading the data stored 
in the data area, the client object receives the data of 
the processing result if the processing of the server ob- 
ject has been correctly completed. If the processing of 
the server object has not been correctly completed, the 
client object receives the status data. 
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Description 

[0001] The present invention relates to a data 
processing method employed when messages are ex- 
changed between objects. The invention also relates to 
a recording medium on which an operating system im- 
plementing the above data processing method is re- 
corded, and to a data processing apparatus provided 
with the above recording medium. 
[0002] Along with recent advances in software pro- 
gramming techniques, the development of software 
based on the object-oriented technique is progressing. 
When the object-oriented technique is applied to soft- 
ware, the functions of the software, such as application 
programs, can be formed into modules by objects. By 
exchanging the required information with each other as 
messages, the objects fulfill their functions as modules. 
Such message exchanges are referred to as "message 
passing". 

[0003] As a method for implementing message pass- 
ing, various techniques have been proposed and have 
been put into practical use. One of the techniques is "fu- 
ture°-based message passing. The basic operation of 
future-based message passing is shown in Fig. 1 . In Fig. 
1 , a message sending object is shown as a client object, 
while a message receiving object is shown as a server 
object. 

[0004] In future-based message passing, a message 
is sent from a client object to a server object, as repre- 
sented by the arrow B1 in Fig. 1 , to request the server 
object to perform predetermined processing. At this 
time, a data area for storing the result of the processing 
executed by the server object is reserved. The data area 
is an area for storing the result to be received by the 
client object, and is referred to as a "future". 
[0005] The server object executes processing, as in- 
dicated by the solid line B2 in Fig. 1 , in accordance with 
the request of the message sent from the client object. 
When the processing is completed, the server object 
stores the processing result in the future, as represented 
by the arrow B3 in Fig. 1 . 

[0006] Meanwhile, the client object continues 
processing, as indicated by the solid line B4 in Fig. 1 , 
after sending the above message to the server object. 
Thereafter, when the client object requires the result of 
the processing performed by the server object, it reads 
the data stored in the future, as represented by the arrow 
B5 in Fig. 1 . 

[0007] At this time, if the result of the processing ex- 
ecuted by the server object has not yet been stored in 
the future, the client object is in a waiting state, as rep- 
resented by the single-dot-chain line B6 in Fig. 1. When 
the processing result sent from the server object is 
stored in the future, it is delivered to the client object 
from the future, as represented by the arrow B7 in Fig. 1 . 
[0008] That is, if the result of the processing executed 
by the server object is stored in the future, the client ob- 
ject immediately receives the processing result. If, how- 



ever, the result of the processing performed by the serv- 
er object has not yet been stored in the future, the client 
object remains in the waiting state before the result is 
stored in the future. 

s [0009] In future-based message passing, such as the 
one illustrated in Fig. 1 , a situation frequently arises in 
which the client object is required to wait for the result 
of the processing executed by the server object after 
sending a message to the server object. 

10 [0010] The above-described situation may occur not 
only when the processing of the server object has not 
yet been completed, but also when the server object has 
hung due to, for example, the occurrence of an error in- 
terrupting the normal execution of the server object. The 

is above-described situation may also occur when mes- 
sage passing is unable to operate due to a breakdown 
of a communication channel, such as a network, re- 
quired for message passing. 

[001 1] If the object cannot exit from the waiting state, 
20 rt appears to the user that a system built into, for exam- 
ple, a set top box, has stopped for an unknown reason. 
[0012] Accordingly, it is desirable that an operating 
system providing a function of future-based message 
passing be able to resume processing of an object even 
25 when the object enters the waiting state due to some 
problem, so that software running on the operating sys- 
tem is stably operated. 

[001 3] In the conventional operating system, with the 
occurrence of a waiting state, time-out processing is of- 

30 ten executed regardless of the reason of the occurrence 
of a waiting-state in order to discontinue the above state. 
In this method, however, the waiting state continues until 
the time-out processing is started, thereby wasting time 
depending on the period set for starting the time-out 

35 processing. Additionally, even if the waiting state is dis- 
continued by the time-out processing, the reason for the 
occurrence of the waiting state cannot be specified, 
which may further cause the occurrence of another wait- 
ing state. 

40 [0014] In view of the above background of the con- 
ventional art, it is an object of the present invention to 
provide a data processing method in which even if an 
object enters a waiting state due to some problem while 
future-based message passing is being performed, the 

45 object can exit from the waiting state without needing to 
execute time-out processing. 

[0015] It is another object of the present invention to 
provide a recording medium on which an operating sys- 
tem implementing the above-described data processing 

50 method is recorded, and to provide a data processing 
apparatus provided with such a recording medium. 
[001 6] In order to achieve the above object, according 
to one aspect of the present invention, there is provided 
a data processing method in which a message is sent 

55 from a client object to a server object, and the server 
object executes processing in response to a request by 
the message and returns a result of the processing to 
the client object. In this method, when a message is sent 
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from the client object to the server object, an area lor 
storing result data indicating the result of the processing 
executed by the server object, and an area for storing 
status data indicating a status of the server object are 
reserved. If the processing executed by the server ob- 5 
ject has been correctly completed, the result data is 
stored in the data area. If the processing executed by 
the server object has not been correctly completed, the 
status data is stored in the data area. By reading the 
data stored in the data area, the client object receives 10 
the result data if the processing executed by the server 
object has been correctly completed. If the processing 
executed by the server object has not been correctly 
completed, the client object receives the status data. 
[0017] According to the aforementioned data is 
processing method, if the processing executed by the 
server object has not been correctly completed, the sta- 
tus data indicating the status of the server object is de- 
livered to the client object via the above-described data 
area. Thus, even if the client object enters the waiting 20 
state due to some problem while message passing is 
being performed, the status of the server object can be 
informed to the client object without needing to execute 
time-out processing, thereby enabling the client object 
to exit from the waiting state. 25 
[0018] According to another aspect of the present in- 
vention, there is provided a recording medium on which 
an operating system is recorded. The operating system 
comprises message sending means, as an application 
program interface for describing an object, for sending 30 
to another object a message that requests it to perform 
processing and to return a result of the processing. The 
aforementioned operating system sends a message 
from a client object to a server object in accordance with 
the message-sending means, and reserves a data area 35 
including a portion for storing result data indicating a re- 
sult of processing executed by the server object and a 
portion for storing status data indicating a status of the 
server object. The operating system further stores the 
result data in the data area if the processing executed 40 
by the server object has been correctly completed. The 
operating system stores the status data in the data area 
if the processing executed by the server object has not 
been correctly completed. 

[0019] The operating system recorded on the record- 45 
ing medium stores the status data indicating the status 
of the server object in the above-described data area if 
the processing executed by the server object has not 
been correctly completed. Accordingly, by reading the 
data stored in the data area, the client object is able to so 
receive the status data. Thus, even if the client object 
enters the waiting state due to some problem while mes- 
sage passing is being performed, the status of the serv- 
er object can be informed to the client object without 
needing to execute time-out processing, thereby ena- 55 
bling the client object to exit from the waiting state. 
[0020] According to a further aspect of the present in- 
vention, there is provided a data processing apparatus 



comprising a recording medium on which an operating 
system is recorded. The operating system comprises 
message-sending means, as an application program in- 
terface for describing an object, for sending to another 
object a message that requests it to perform processing 
and to return a result of the processing. The aforemen- 
tioned operating system sends a message from a client 
object to a server object in accordance with the mes- 
sage-sending means, and reserves a data area includ- 
ing a portion for storing result data indicating a result of 
processing executed by the server object and a portion 
for storing status data indicating a status of the server 
object. The operating system stores the result data in 
the data area if the processing executed by the server 
object has been correctly completed. The operating sys- 
tem stores the status data in the data area if the process- 
ing executed by the server object has not been correctly 
completed. 

[0021] The operating system recorded on the record- 
ing medium provided with the data processing appara- '. 
tus stores the status data of the server object in the 
above-described data area if the processing executed 
by the server object has not been correctly completed. 
Accordingly, by reading the data stored in the data area, 
the client object is able to receive the status data. Thus, 
even if the client object enters the waiting state due to : 
some problem while message passing is being per- 
formed, the status of the server object can be informed ^ 
to the client object without needing to execute time-out - - 
processing, thereby enabling the client object to exit 4 - 
from the waiting state. ...u *..*-■ 

[0022] In this specification, software for managing the 
execution of application programs is referred to as "an 
operating system" in a broad sense. That is, the oper- 
ating system described in this specification includes not 
only basic software for managing hardware, but also, - ; - 
software operating on basic software for managing**- 
hardware and managing the execution of application 
programs, which is referred to as, "middleware". Fur-* 
ther, the operating system described in this specification 
includes software implementing a virtual computer sys- 
tem, in which a plurality of program execution environ- 
ments are implemented by a single computer, and it ap- 
pears to the user that a plurality of computers were op- 
erating. 

[0023] Embodiments of the invention will now be de- 
scribed, by way of example only, with reference to the 
accompanying drawings, in which: 

Fig. 1 illustrates the basic operation of message 
passing performed by using a future; 
Fig. 2 illustrates the schematic configuration of an 
example of a television set incorporating the 
present invention; 

Fig. 3 illustrates the operating system installed in 
the television set shown in Fig. 2; 
Fig. 4 illustrates an example of a scenario of mes- 
sage passing performed by using the method 
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"SendWithRBox" when the processing proceeds in 
a normal condition; 

Fig. 5 illustrates an example of a scenario of mes- 
sage passing performed by using the method 
"SendWithRBox" when an exception occurs; 
Fig. 6 illustrates an example of a scenario of mes- 
sage passing performed in the server object in 
which a processing request is received and a 
processing result is returned by different server ob- 
jects; 

Fig. 7 illustrates an example of a scenario of mes- 
sage passing performed by using the method 
"SendWithContinuation"; and 
Fig. 8 illustrates an example of a scenario of mes- 
sage passing performed between different 
metaSpaces. 

1 . Hardware Environment 

[0024] An example of a data processing apparatus in- 
corporating the present invention is first described with 
reference to Fig. 2. As an embodiment of the present 
invention, a television set loaded with a data processing 
function incorporating the present invention is de- 
scribed. However, the present invention is applicable to 
other types of data processing apparatuses. That is, the 
present invention is widely used in data processing ap- 
paratuses on which an operating system runs, for ex- 
ample, audio-visual machines (what is called, °AV ma- 
chines") other than the television set, office machines, 
and ordinary computers. 

[0025] The television set shown in Fig. 2, which 
serves as the data processing apparatus incorporating 
the present invention, receives a signal from a broad- 
cast station via an antenna or a cable (neither of them 
is shown), and based on the signal, displays an image 
on an image display unit, such as a cathode ray tube or 
a liquid crystal panel, and also outputs sound from a 
speaker. 

[0026] The television set is not only provided with an 
ordinary television function, but is also able to receive 
programs and data from an external source. The televi- 
sion set is formed of, as illustrated in Fig. 2, a television 
function unit 3 connected to a bus 2 via a bus/input out- 
put (IO) bridge 1 , a processor 5 connected to the bus 2 
via a bus/memory bridge 4, a read only memory (ROM) 
6 and a random access memory (RAM) 7 connected to 
the processor 5 via the bus/memory bridge 4, and an 
operation panel 8, an external storage device 9, a com- 
munication unit 10, and a graphics device 11, all of which 
are connected to the bus 2. 

[0027] The television function unit 3 serves the func- 
tion of reproducing images and sounds based on a sig- 
nal received by the antenna or the cable (neither of them 
is shown). The television function unit 3 is connected to 
the bus 2 via the bus/lO bridge 1 so that it can transmit 
or receive signals to or from the other elements. 
[0028] The processor 5, which serves as a computa- 



tion unit for controlling the individual elements of the tel- 
evision set, is connected to the bus 2 via the bus/mem- 
ory bridge 4. The ROM 6 and the RAM 7 are connected 
to the processor 5 via the bus/memory bridge 4. 

5 [0029] The ROM 6 stores an operating system and 
application programs used for the control performed by 
the processor 5. The operating system stored in the 
ROM 6 is an object-oriented operating system imple- 
menting object orientation. 

io [0030] The RAM 7 is used as a work area for the proc- 
essor 5. More specifically, the processor 5 runs the op- 
erating system and the application programs stored in 
the ROM 6 by using the RAM 7 as a work area, thereby 
controlling the individual elements of the television set. 

15 [0031] The operation panel 8 is an input unit for re- 
ceiving the operation which is input by the user, and a 
signal indicating an instruction for, for example, the 
switching of the channel or the volume control of the tel- 
evision set, is input from this operation panel 8. More 

20 specifically, the operation panel 8 is formed of an input 
unit provided with a plurality of buttons for inputting var- 
ious signals and a pointing device, i.e., a mouse. The 
signal input through the operation panel 8 is input into 
the processor 5 via the bus 2 and the bus/memory 

25 bridge 4. The processor 5 then executes predetermined 
computational processing based on the signal input 
through the operation panel 8, thereby controlling the 
individual elements. 

[0032] The external storage device 9, which is formed 
30 of, for example, a hard disk drive unit, is used for record- 
ing data, such as images and sounds, control data re- 
quired for controlling the television set, application pro- 
grams externally downloaded via the communication 
unit 10, etc. 

35 [0033] The communication unit 10, which is an input/ 
output unit for performing data communications with an 
external source, is formed of a modem, a terminal adapt- 
er, etc. 

[0034] The graphics device 1 1 processes data record- 

40 ed on the external storage device 9 and data received 
from an external source via the communication unit 10, 
and displays the corresponding images. 
[0035] The television set not only includes an ordinary 
television function provided by the television function 

45 unit 3, but also receives data from an external source 
via the communication unit 10. More specifically, the tel- 
evision set is able to receive, for example, a new soft- 
ware module from an external network via the commu- 
nication unit 10, thereby upgrading the version of the 

50 operating system and the application programs. 

[0036] In this television set, the processor 5 runs the 
operating system stored in the ROM 6, and also exe- 
cutes the application programs stored in the ROM 6 and 
in the external storage device 9 on the operating system, 

55 thereby controlling the individual elements of the televi- 
sion set. That is, the television set is provided with the 
ROM 6, which serves as a computer-readable recording 
medium on which the operating system is recorded. 
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[0037] The operating system may be stored in the 
RAM 7 or the external storage device 9, particularly 
when it is desired that the operating system be overwrit- 
ten. 

2. Software Environment 

[0038] The software environment of the above-de- 
scribed television set is now described. 

2-1 Schematic Configuration of Operating System 

[0039] The operating system used in the aforemen- 
tioned television set is an object-oriented operating sys- 
tem. In other words, software, such as an application 
program, running on the operating system is formed into 
modules as objects, and object interaction is conducted 
by message passing. 

[0040] This operating system has a micro-kernel, as 
shown in Fig. 3, that provides the basic function as the 
operating system, thereby making it possible to simul- 
taneously provide a plurality of program execution en- 
vironments on the micro-kernel. In the following descrip- 
tion, the program execution environment provided by 
the operating system is referred to as a "metaSpace". 
[0041] More specifically, the operating system pro- 
vides, as a metaSpace, an mCOOP metaSpace con- 
structed by a plurality of objects, and an mDrive 
metaSpace constructed by a plurality of objects. An ap- 
plication program interface (hereinafter referred to as an 
"API") used for describing objects of an application pro- 
gram is assigned to each metaSpace. In the following 
description, an object used in a metaSpace is referred 
to as a "metaObject". 

[0042] The mCOOP metaSpace is a metaSpace pri- 
marily for operating an object-oriented application pro- 
gram (for example, an application program for imple- 
menting a graphical user interface for controlling the op- 
eration panel 8). The "m" in mCOOP metaSpace repre- 
sents a metaSpace, and "COOP" stands for Concurrent 
Object Oriented Programming. 

[0043] The mDrive metaSpace is a metaSpace for op- 
erating a device driver (for example, a device driver for 
controlling the graphics device 11 or a device driver for 
controlling the communication unit 10 to transmit and 
receive data via a network) primarily for controlling hard- 
ware. The "m" in mDrive metaSpace designates a 
metaSpace, and "Drive" represents a metaSpace for 
operating the device driver (Device Driver). 
[0044] That is, in this operating system, the mCOOP 
metaSpace and the mDrive metaSpace are operated on 
the micro-kernel. An application program formed into 
modules as objects is operated in the mCOOP 
metaSpace, while a device driver formed into modules 
as objects is operated in the mDrive metaSpace. 
[0045] This operating system is able to provide not on- 
ly mCOOP metaSpace and mDrive metaSpace, as the 
metaSpace operating on the micro-kernel, but also a 



metaSpace for operating, for example, a procedure-ori- 
ented application program (for example, an application 
program for causing the television function unit 3 to dis- 
play moving pictures). 

5 [0046] The metaObject forming mCOOP metaSpace 
includes, for example, an object "mCOOPMailer" and 
an object "mCOOPFaultHandler". The object "mCOOP- 
Mailer" is a metaObject used for performing message 
passing between application programs running in the 

io mCOOP metaSpace. The object "mCOOPFaultHan- 
dler" is a metaObject for executing exception handling. 
In practice, the mCOOP metaSpace is formed, not only 
of the above-described metaObjects, but also of other 
metaObjects. 

is [0047] The metaObject forming mDrive metaSpace 
includes, for example, an object "mDriveMailer" and an 
object "mDriveFaultHandler". The object "mDriveMail- 
er" is a metaObject used for performing message pass- 
ing between device drivers running in the mDrive 

20 metaSpace. The object "mDriveFaultHandler" is a . 
metaObject for executing exception handling. In prac- 
tice, the mDrive metaSpace, as well as the mCOOP 
metaSpace, is formed not only of the above-described 
metaObjects, but also of other metaObjects. 

25 [0048] This operating system provides the function of 
future-based message passing, which is discussed in 
detail below. In the following description, in the future^ 
based message passing, the object that sends a mes- . 
sage to another object to request it to execute process^ 

30 jng is referred to as a "client object". Conversely, the ob-; * 
ject that receives the message from the client object and ' t 
executes processing based on the message is referred 
to as a "server object". , 

35 2-2 mCOOP metaSpace API 

[0049] In order to perform future-based message*, 
passing in the mCOOP metaSpace, the aforementioned 
operating system provides the following methods as the 
40 APIs used for describing the objects operating in the 
mCOOP metaSpace. In this specification, the API is in- 
dicated according to the description method of the Ob- 
ject Management Group Interface Definition Language 
(OMG IDL). 

45 

sError SendWithRBox(in OID destObjID, in Selec- 
tor meth, in any msg, in size_t sizeOfMsg, out RID 
rBoxlD) 

sError Receive(in RID rBoxlD, in any msg, in size_t 
50 sizeOfMsg) 

sError Reply (in any resultMsg, in size_t sizeOf Re- 
sult Msg) 

sError Delegate (in OID destObjID, in Selector 
meth, in any msg, in size_t sizeOfMsg) 

55 

[0050] The above methods are discussed below in 
detail. 
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2-2-1 SendWithRBox() 

sError SendWithRBox(in OID destObjlD, in Selector 
meth, in any msg, in size_t sizeOfMsg, out RID rBoxlD) 

[0051] The method "SendWithRBox" is a message- 
sending method for sending a message from a client ob- 
ject to a server object. That is, the method "SendWith- 
RBox" is employed when it becomes necessary for the 
client object to obtain the result of the processing exe- 
cuted by the server object after it has sent a message 
to the server object. 

[0052] The argument "destObjlD" is an argument of 
the "OID" type, which is a data type for specifying the 
object. The value specifying the server object is set in 
the argument "destObjlD". 

[0053] The argument "meth" is an argument of the 
•Selector" type, which is a data type for designating the 
method. The value designating the method of the server 
object for describing the processing to be requested is 
set in the argument "meth". 

[0054] The argument "msg" is an argument of the 
"any" type, which is an arbitrary data type. The pointer 
to the area for storing the message to be delivered to 
the server object is set in the argument "msg". 
[0055] The argument "sizeOfMsg" is an argument of 
the "size_t" type, which is a data type for specifying the 
size of the data. The value indicating the size of the mes- 
sage to be delivered to the server object is set in the 
argument "sizeOfMsg". 

[0056] When the method "SendWithRBox" is issued, 
the data area "RBox" for storing the result of the 
processing executed by the server object is reserved by 
the object "mCOOPMailer", which will be discussed lat- 
er. The data area "RBox" is an area in which the result 
to be received by the client object is stored, and is re- 
ferred to as a "future". 

[0057] After sending the message to the server ob- 
ject, the method "SendWithRBox" obtains the identifier 
"rBoxlD"of the "RID" type, which is a data type for spec- 
ifying the data area "RBox". The identifier "RBoxlD" is 
an identifier for designating the data area "RBox" re- 
served by the object "mCOOPMailer" when the method 
"SendWithRBox" has been issued. 
[0058] The method "SendWithRBox" acquires the 
value of the "sError" type as the return value, which is 
a data type representing the error code. That is, if the 
processing of the "SendWithRBox" is not correctly com- 
pleted in issuing this method, the error code indicating 
the error reason is returned as the return value. If the 
processing is correctly completed, the value indicating 
that the processing has been correctly completed is re- 
turned as the return value. 
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2-2-2 Receive() 

sError Receive(in RID rBoxlD, in any msg, in size_t 
sizeOfMsg) 

5 

[0059] The method "Receive" is a data reading meth- 
od for reading data stored in the data area "RBox". That 
is, the method "Receive" is used when the client object 
receives the result of the processing executed by the 
io server object after it has issued the method "SendWith- 
RBox". 

[0060] The argument "rBoxlD" is an argument of the 
"RID" type, which is a data type for designating the data 
area "RBox". The identifier for specifying the data area 

is "RBox" which stores the result of the processing per- 
formed by the server object is set in the argument "rBox- 
lD". That is, the value of the identifier "rBoxlD" acquired 
upon issuing the method "SendWithRBox" is set in the 
argument "rBoxlD". 

20 [0061] The argument "msg" is an argument of the 
"any" type, which is an arbitrary data type. The pointer 
to the area for storing the received message is set in the 
argument "msg". 

[0062] The argument "sizeOfMsg" is an argument of 
25 the "size_t" type, which is a data type for specifying the 
size of the data. The value indicating the size of the area 
for storing the received message is set in the argument 
"sizeOfMsg". 

[0063] The method "Receive" acquires the value of 
30 the "sError" type as the return value, which is a datatype 
representing the error code. That is, if the processing of 
the "Receive" is not correctly completed in issuing this 
method, the error code indicating the error reason is re- 
turned as the return value. If the processing is correctly 
35 completed, the value indicating that the processing has 
been correctly completed is returned as the return value. 

2-2-3 ReplyQ 



[0064] The method "Reply" is used when the server 
object returns the processing result to the client object 
45 after the ctient object has sent the method "SendWith- 
RBox". 

[0065] The argument "resuItMsg" is an argument of 
the "any" type, which is an arbitrary data type. The point- 
er to the area for storing the message to be sent to the 

50 client object is set in the argument "resuItMsg". 

[0066] The argument "sizeOfResultMsg" is an argu- 
ment of the "size_t" type, which is a data type for des- 
ignating the size of the data. The value indicating the 
size of the message to be sent to the client object is set 

55 in the argument "sizeOfResultMsg". 

[0067] The method "Reply" obtains the value of the 
"sError" type as the return value, which is a data type 
representing the error code. That is, if the processing of 
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40 sError Reply(in any resuItMsg, in size_J 
sizeOfResultMsg) 
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the "Reply" is not correctly completed in issuing this 
method, the error code indicating the error reason is re- 
turned as the return value. If the processing is correctly 
completed, the value indicating that the processing has 
been correctly completed is returned as the return value, s 

2-2-4 Delegate() 

sError Delegate (in OID destObjID, in Selector meth, in 
any msg, in size_t sizeOfMsg) 10 

[0068] The method "Delegate" is an authorization del- 
egating method for delegating an authorization among 
objects. More specifically, the method "Delegate" is 
used when the authorization to return the result of the is 
processing executed by the server object to the client 
object is delegated among a plurality of server objects. 
[0069] In the following description, the above-men- 
tioned authorization is referred to as the "reply authori- 
zation". Among the server objects, the object that dele- 20 
gates the reply authorization is referred to as an "author- 
ization-delegating object", while the object that is dele- 
gated to receive the reply authorization is referred to as 
an "authorization -delegated object". 

[0070] The argument "destObjID" is an argument of 25 
the "OID" type, which is a data type for specifying the 
object. The value representing the authorization-dele- 
gated object is set in the argument "destObjID". 
[0071] The argument "meth" is an argument of the 
"Selector" type, which is a data type for specifying the 30 
method. The value indicating the method of the author- 
ization-delegated object for describing the required 
processing is set in the argument "meth". 
[0072] The argument "msg" is an argument of the 
"any" type, which is an arbitrary data type. The pointer 35 
to the area for storing the message to be sent to the 
authorization-delegated object is set in the argument 
"msg". 

[0073] The argument "sizeOfMsg" is an argument of 
the "size_t" type, which is a data size for designating the 40 
size of the data. The value representing the size of the 
message to be sent to the authorization-delegated ob- 
ject is set in the argument "sizeOfMsg". 
[0074] The method "Delegate" obtains the value of 
the "sError" type as the return value, which is a data type 45 
representing the error code. That is, if the processing of 
the "Delegate" is not correctly completed in issuing this 
method, the error code indicating the error reason is re- 
turned as the return value. If the processing is correctly 
completed, the value indicating that the processing has so 
been correctly completed is returned as the return value. 

2-3 m Drive metaSpace API 

[0075] In order to perform future-based message ss 
passing in the mDrive metaSpace, the aforementioned 
operating system provides the following methods as the 
APIs used for describing the objects operating in the 
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mDrive metaSpace. The API is represented in compli- 
ance with the OMG IDL. 

sError SendWithContinuation(in OID destObjID, in 
Selector meth, in any msg, in size_t sizeOfMsg, in 
Selector contMeth) 

sError Kick(in ContID contID, in any msg, in size_t 
sizeOfMsg) 

[0076] The above methods are described in detail be- 
low. 

2-3-1 SendWithContinuation() 

sError SendWithContinuation(in OID destObjID, in 
Selector meth, in any msg, in size_t sizeOfMsg, in 
Selector contMeth) 

[0077] The method "SendWithContinuation" is a mes- 
sage-sending method for sending a message from the - 
client object to the server object. The method "Send- 
WithContinuation" is used when it becomes necessary 
for the client object to perform a specific method (here- 
inafter referred to as a "continuation method") upon re- 
ceiving the processing result of the server object after 
the client object has sent the message to the server ob- 
ject. 

[0078] The argument "destObjID" is an argument of 
the "OID" type, which is a data type for specifying the 
object. The value for specifying the server object is set «* 
in the argument "destObjID". * , .* * 

[0079] The argument "meth" is an argument of the 
"Selector" type, which is a data type for designating the' 
method. The value representing the method of the serv-- y 
er object for describing the requested processing is seb 
in the argument "meth". v 
[0080] The argument "msg" is an argument of the 
"any" type, which is an arbitrary data type. The pointerK.. 
to the area for storing the message to be delivered to * 
the server object is set in the argument "msg". 
[0081] The argument "sizeOfMsg" is an argument of 
the "size_t" type, which is a data type for specifying the 
size of the data. The value indicating the size of the mes- 
sage to be delivered to the server object is set in the 
argument "sizeOfMsg". 

[0082] The argument "contMeth" is an argument of - 
the "Selector" type, which is a data type for designating 
the method. The value for specifying the continuation 
method is set in the argument "contMeth". 
[0083] Upon issuing the method "SendWithContinua- 
tion", the data area "Continuation" is reserved by the ob- 
ject "mDriveMailer", which will be discussed later, and 
the information concerning the continuation method is 
stored in the data area "Continuation". The data area 
"Continuation" is an area for storing the continuation 
method to be executed by the client object, and is re- 
ferred to as a "future". 

[0084] The method "SendWithContinuation" acquires 
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the value of the "sError" type as the return value, which 
is a data type representing the error code. That is, if the 
processing of the "SendWithContinuation" is not cor- 
rectly completed in issuing this method, the error code 
indicating the error reason is returned as the return val- 
ue. If the processing is correctly completed, the value 
indicating that the processing has been correctly com- 
pleted is returned as the return value. 

2-3-2 Kick() 

sError Kick(in ContID contID, in any msg, in size_t 
sizeOfMsg) 

[0085] The method "Kick" is employed when the serv- 
er object instructs the client object to execute the con- 
tinuation method after the client object has issued the 
method "SendWithContinuation". 
[0086] The argument "contID" is an argument of the 
"contID" type, which is a data type for designating the 
data area "Continuation". The identifier for specifying 
the data area "Continuation" reserved by the object 
"m Drive Mailer" upon issuing the method "SendWith- 
Continuation" is set in the argument "contID". 
[0087] The argument "msg" is an argument of the 
"any" type, which is an arbitrary data type. The pointer 
to the area for storing the message to be delivered to 
the client object is set in the argument "msg". 
[0088] The argument "sizeOfMsg" is an argument of 
the "size_t" type, which is a data type for specifying the 
size of the data. The value representing the size of the 
message to be delivered to the client object is set in the 
argument "sizeOfMsg". 

[0089] The method "Kick" obtains the value of the 
"sError" type as the return value, which is a data type 
representing the error code. That is, if the processing of 
the "Kick" is not correctly completed in issuing this meth- 
od, the error code indicating the error reason is returned 
as the return value. If the processing is correctly com- 
pleted, the value indicating that the processing has been 
correctly completed is returned as the return value. 

2-4 Data Area Used for Message Passing 

[0090] In performing message passing in the mCOOP 
metaSpace, the aforementioned operating system uses 
the data area "RBox" as a future, and also uses the data 
area "DeliveryBoxA" for delivering information from the 
client object to the server object. 
[0091] Further, in performing message passing in the 
mDrive metaSpace, the aforementioned operating sys- 
tem uses the data area "Continuation" as a future, and 
also uses the data area " Deli very BoxB" for delivering 
information from the client object to the server object. 
[0092] The above-described operating system re- 
serves the data area "Thread" for each object in order 
to store the information used for managing the execution 
state of the object. The operating system also stores the 



information concerning the future in the data area 
"Thread". The object is operating as a single thread in 
the mCOOP metaSpace and in the mDrive metaSpace, 
one thread corresponding to one object. The information 
s concerning the thread is stored in the data area "Thread" 
as the information for managing the execution state of 
the object. 

[0093] The data areas "RBox", "DeliveryBoxA", "Con- 
tinuation", "DeliveryBoxB", and Thread" are data areas 

10 used by the operating system for providing the function 
of the message passing or for managing the object. 
These data areas are managed by the operating system 
so that they cannot be directly accessed by the applica- 
tion programs or the device drivers. The above-de- 

15 scribed data areas are discussed in detail below. 

2-4-1 RBox 

[0094] The data area "RBox" is reserved by the object 
20 "mCOOPMailer" upon issuing the method "SendWithR- 
Box". More specifically, the reservation of the data area 
"RBox" by the object "mCOOPMailer" is performed by 
creating the instances of a class (hereinafter referred to 
as the "class 'RBox'") having attributes shown in Table 
25 1 . in Table 1 , among the attributes of the class "RBox", 
only a minimal number of attributes required for imple- 
menting the basic form of message passing in the 
mCOOP metaSpace are shown. Attributes other than 
the attributes shown in Table 1 may be included. 

30 



Table 1 



RBox 


ThreadID 


creator 


bool 


ready 


void* 


resultMsg 


t_size 


sizeOf Result Msg 


sError 


status 



[0095] Table 1 shows that the class "RBox" has an at- 
tribute "creator" of the "ThreadID" type, which is a data 
type for specifying the data area "Thread" to be set for 
each object. 

[0096] The class "RBox" also has an attribute "ready" 
of the "boor type, which is a data type for logical values, 
an attribute "resultMsg" of the "void*" type, which is a 
data type representing the pointer, and an attribute 
"sizeOf ResultMsg" of the "size_t" type, which is a data 
size for specifying the size of the data. These attributes 
are used as the area for storing the result data of the 
processing executed by the server object. 
[0097] The class "RBox" further has an attribute "sta- 
tus" of the "sError" type, which is a data type indicating 
the error code, as the area for storing the data repre- 
senting the status of the server object. 
[0098] The identifier for specifying the data area 
Thread" corresponding to the object that has created 



40 



45 



50 



8 



15 



EP 0 940 750 A2 



the data area "RBox" (i.e., the client object that has is- 
sued the method "SendWithRBox") is set in the attribute 
"creator 1 *. In the mCOOP metaSpace, the object is op- 
erating as a single thread, as discussed above, and one 
data area "Thread" is assigned to one object. Accord- 
ingly, if the data area "Thread" is specified by the at- 
tribute "creator", the corresponding client object is de- 
termined. 

[0099] The value indicating whether the processing 
result of the server object has been returned is set in the 
attribute "ready". In other words, the attribute "ready" is 
a flag indicating whether the result message to be re- 
turned from the server object to the client object is ready. 
[01 00] The pointer to the area for storing the message 
to be delivered to the client object as the processing re- 
sult of the server object is set in the attribute "resultMsg". 
[0101] The value representing the size of the mes- 
sage to be delivered to the client object as the process- 
ing result of the server object is set in the attribute "size- 
OfResultMsg". 

[01 02] The code indicating the status of the server ob- 
ject as the information to be reported to the client object 
is set in the attribute "status". More specifically, if the 
processing of the server object is not correctly complet- 
ed due to the occurrence of an exception interrupting 
the normal execution of the server object, the message 
indicating a failure in performing normal processing is 
reported to the object "m COOP Mailer" from the object 
"mCOOPFaultHandler", which will be discussed later. 
Thus, the error code indicating the status of the server 
object is set in the attribute "status" by the object 
"mCOOPMailer". If the processing is correctly executed 
by the server object, the value indicating that the server 
object is in a normal status is set in the attribute "status". 
[0103] When the method "Receive" is issued by the 
client object, the client object refers to the attribute 
■ready" so as to determine whether the result of the 
processing executed by the server object has been re- 
turned. If the processing result of the server object has 
been returned, the client object refers to the attribute 
"resultMsg" so as to specify the area for storing the mes- 
sage to be delivered to the client object as the process- 
ing result of the server object, thereby reading the data 
having the size indicated by the attribute "sizeOfRe- 
sultMsg" from the above-mentioned area. As a result, 
the message to be delivered to the client object is read 
and delivered to the client object. 

2-4-2 DeliveryBoxA 

[0104] Upon issuing the method "SendWithRBox", 
the data area "DeliveryBoxA" is reserved by the object 
"mCOOPMailer" to deliver information from the client 
object to the server object. More specifically, the reser- 
vation of the data area "DeliveryBoxA" by the object 
"mCOOPMailer" is performed by creating the instances 
of a class (hereinafter referred to as the "class 'Deliver- 
yBoxA'" having attributes shown in Table 2. In Table 2, 
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among the attributes of the class "DeliveryBoxA", only 
a minimal number of attributes required for implement- 
ing the basic form of message passing in the mCOOP 
metaSpace are shown. Attributes other than the at- 
5 tributes shown in Table 2 may be included. 



Table 2 



DeliveryBoxA 


RID 


rBoxlD 


void* 


msg 


t_size 


sizeOfMsg 



[0105] Table 2 shows that the class "DeliveryBoxA" 
*s has an attribute "rBoxlD" of the "RID" type, which is a 
data type for specifying the data area "RBox", an at- 
tribute "msg" of the "void*" type, which is a data type 
indicating the pointer, and an attribute "sizeOfMsg" of 
the "size J" type, which is a data size for designating the 
20 size of the data. 

[0106] The identifier for specifying the data area 
"RBox" used for performing message passing using the 
data area "DeliveryBoxA" is set in the attribute "rBoxlD". 
[01 07] The pointer to the area for storing the message 
25 to be delivered from the client object to the server object 
is set in the attribute "msg". 

[0108] The value representing the size of the mes-' • 
sage to be delivered from the client object to the server L 
object is set in the attribute "sizeOfMsg". 

30 [0109] By using the data area "DeliveryBoxA" re- * 
served by creating the instances of the class "Delivery- 1 
BoxA", the operating system is able to send the infor- 
mation concerning the data area "RBox" together with 
the message that is sent from the client object to the r * 

35 server object. In other words, by using the data area'" 
"DeliveryBoxA", the operating system is able to simul- * 
taneously handle the message and the future in the 
mCOOP metaSpace. f> 

40 2-4-3 Continuation 

[011 0] Upon issuing the method "SendWith Continua- 
tion", the data area "Continuation" is reserved by the ob- 
ject "mDriveMailer" in order to store the information con- 

4 & cerning the continuation method therein. More specifi- 
cally, the reservation of the data area "Continuation" by 
the object "mDriveMailer" is performed by creating the 
instances of a class (hereinafter referred to as the "class 
"Continuation"') having attributes indicated in Table 3. In 

so Table 3, among the attributes of the class "Continua- 
tion", only a minimal number of attributes required for 
implementing the basic form of message passing in the 
mDrive metaSpace are shown. Attributes other than the 
attributes shown in Table 3 may be included. 

55 
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Table 3 



Continuation 


Thread ID 
Selector 


creator 
meth 



[0111] Table 3 indicates that the class "Continuation" 
has an attribute "creator" ot the "ThreadlD" type, which 
is a data type for specifying the data area "Thread" set 
for each object, and an attribute "meth" of the "Selector" 
type, which is a data type for designating the method. 
[0112] The identifier for specifying the data area 
"Thread" corresponding to the object that has created 
the data area "Continuation" (i.e., the client object that 
has issued the method "SendWithContinuation") is set 
in the attribute "creator". In the mDrive metaSpace, the 
object is operating as a single thread, as discussed 
above, and one data area "Thread" corresponds to one 
object. Accordingly, when the data area "Thread" is 
specified by the attribute "creator", the corresponding 
client object is determined. 

[01 1 3] The value representing the continuation meth- 
od of the client object is set in the attribute "meth". 
[0114] When the method "Kick" is issued by the server 
object, the client object refers to the attribute "meth" so 
as to specify the continuation method of the client object, 
thereby starting the specified continuation method. 

2-4-4 DeliveryBoxB 

[01 1 5] Upon issuing the method "SendWithContinua- 
tion", the data area "DeliveryBoxB" is reserved by the 
object "mDriveMailer" in order to deliver information 
from the client object to the server object. More specif- 
ically, the reservation of the data area "DeliveryBoxB" 
by the object "mDriveMailer" is conducted by creating 
the instances of a class (hereinafter referred to as the 
"class 'De livery BoxB ,n ) having attributes indicated in Ta- 
ble 4. In Table 4, among the attributes of the class "De- 
liveryBoxB", only a minimal number of attributes re- 
quired for implementing the basic form of message 
passing in the mDrive metaSpace are shown. Attributes 
other than the attributes shown in Table 4 may be in- 
cluded. 



Table 4 



DeliveryBoxB 


ContlD 


contID 


void* 


msg 


t_size 


sizeOfMsg 



[0116] Table 4 shows that the class "DeliveryBoxB" 
has an attribute "contID" of the "ContlD" type, which is 
a data type for designating the data area "Continuation", 
an attribute "msg" of the "void*" type, which is a data 
type indicating the pointer, and an attribute "sizeOfMsg" 



of the "size_t" type, which is a data type for specifying 
the size of the data. 

[0117] The identifier for specifying the data area "Con- 
tinuation" used for message passing employing the data 
s area "DeliveryBoxB" is set in the attribute "contID". 
[0118] The pointer to the area for storing the message 
to be delivered from the client object to the server object 
is set in the attribute "msg". 

[0119] The value indicating the size of the message 
10 to be delivered from the client object to the server object 
is set in the attribute "sizeOfMsg". 
[0120] By using the data area "DeliveryBoxB" re- 
served by creating the instances of the class " Delivery- 
BoxB" , the operating system is able to send the inf or- 
is mation concerning the data area "Continuation" togeth- 
er with the message that is sent from the client object to 
the server object. In other words, by using the data area 
"DeliveryBoxB", the operating system is able to simul- 
taneously handle the message and the future in the 
20 mDrive metaSpace. 

2-4-5 Thread 

[0121] In the mCOOP metaSpace and in the mDrive 
2s metaSpace, as noted above, the object is operating as 
a single thread, and one thread is assigned to one ob- 
ject. The information concerning each thread is stored 
in the data area "Thread" as the information for manag- 
ing the execution state of the object. That is, the oper- 
30 ating system reserves the data area "Thread" for each 
object in order to store the information for managing the 
execution state of the object therein. 
[0122] As the information for managing the execution 
state of the object, for example, the information indicat- 
es ing whether the object is in the waiting state or in the 
execution state, is stored in the data area "Thread". In 
performing future-based message passing, the informa- 
tion concerning the future is atso stored in the data area 
"Thread". 

40 [0123] More specifically, it is now assumed that the 
object is operating in the mCOOP metaSpace. In per- 
forming future-based message passing, the identifier 
"rBoxlD" for specifying the data area "RBox" used for 
message passing is stored by the object "mCOOPMail- 

45 er", as the information concerning the future, in the data 
area "Thread" corresponding to the object. 
[0124] It is now assumed that the object is operating 
in the mDrive metaSpace. In conducting future-based 
message passing, the identifier "contID" for specifying 

so the data area "Continuation" used for message passing 
is stored by the object "mDriveMailer" in the data area 
"Thread" corresponding to the object. 

2-5 Message Passing 

55 

[01 25] A detailed description is given below by taking 
specific scenarios, as examples, of message passing 
performed by using the aforementioned methods and 



10 



19 

data areas. 

[0126] Figs. 4 through 8 illustrate a shift of processing 
and message exchange performed in message pass- 
ing. In Figs. 4 through 8, the single-dot-chain arrows 
designate a shift of processing and message exchange 5 
within the operating system, while the solid arrows indi- 
cate a shift of processing and message exchange from 
the point of view of the application program. 

2-5-1 Message Passing Using SendWithRBoxQ 10 

[0127] A description is given below of message pass- 
ing performed by using the method "SendWithRBox" in 
the mCOOP metaSpace when the processing proceeds 
in a normal condition and when an exception occurs. is 

2-5-1-1 When Processing is Executed in a Normal 
Condition 

[0128] A description is first given, with reference to 20 
Fig. 4, of message passing performed by using the 
method "SendWithRBox - in the mCOOP metaSpace 
when the processing is executed in a normal condition 
without the occurrence of an exception. 
[0129] Fig. 4 illustrates a basic scenario of message 2s 
passing performed by using the method "SendWithR- 
Box" between an object A operating as an application 
program in the mCOOP metaSpace and an object B op- 
erating as an application program in the mCOOP 
metaSpace. That is, in this example, the object A is a 30 
client object, while the object B is a server object. 
[0130] When the object A issues the method "Send- 
WithRBox", as indicated by ST1-1, the processing is 
shifted to the object "mCOOPMailer", as represented by 
the single-dot-chain arrow ST1 -2, and the processing in 35 
accordance with the method "SendWithRBox" is exe- 
cuted by the object "mCOOPMailer", as designated by 
ST1-3. 

[0131] The object "mCOOPMailer" first reserves the 
data area "RBox" for storing the result of processing ex- 40 
ecuted by the server object (in this example, the object 
B), and sets the identifier for specifying the data area 
■Thread" corresponding to the object A in the attribute 
"creator" of the data area "RBox". 

[01 32] The object "mCOOPMailer" then reserves the 45 
data area "Delivery Box A", and stores the identifier 
"rBoxlD" for specifying the data area "RBox" and the 
message sent by the method "SendWithRBox" therein. 
[01 33] The identifier "rBoxlD" for designating the data 
area "RBox" is stored in the data area "DeliveryBoxA", so 
and more specifically, the value of the identifier "rBoxlD" 
for specifying the data area "RBox" is set in the attribute 
"rBoxlD" of the data area "DeliveryBoxA". 
[0134] The message sent by the method "SendWith- 
RBox" is stored in the data area "DeliveryBoxA", and 55 
more specifically, the value of the argument "msg" of the 
method "SendWithRBox" is set in the attribute "msg" of 
the data area "DeliveryBoxA", and also, the value of the 
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argument "sizeOf Msg" of the method "SendWithRBox" 
is set in the attribute "sizeOf Msg" of the data area "De- 
liveryBoxA". 

[0135] Thereafter, the object "mCOOPMailer" deliv- 
ers to the object B, as indicated by the single-dot-chain 
arrow ST1 -4, the data stored in the data area "Deliver- 
yBoxA", i.e., the message sent by the method "Send- 
WithRBox", and the identifier "rBoxlD" for specifying the 
reserved data area "RBox", thereby starting the method 
of the object B. 

[0136] In this case, only the message is delivered to 
the method of the object B, and the identifier "rBoxlD" 
is stored in the data area "Thread" corresponding to the 
object B. In other words, the identifier "rBoxlD" to be de- 
livered to the object B is under the management of the 
operating system, and it is only the message that has 
sent to the object B, from the point of view of the appli- 
cation program. 

[01 37] In starting the method of the object B by deliv- 
ering the data stored in the data area "DeliveryBoxA" 
from the object "mCOOPMailer" to the object B, the ob- 
ject B is specified by the argument "destObjID" of the 
method "SendWithRBox", and the method of the object 
B is designated by the argument "meth" of the method 
"SendWithRBox". 

[01 38] Upon completing the aforementioned process- * 
ing, as represented by the single-dot-chain arrow* 
ST1-5, the object "mCOOPMailer" returns to the object - 
A the identifier "rBoxlD" for specifying the reserved data - 
area "RBox", and also returns to the object A the valuer ' 
indicating that the processing has been correctly com- v 
pleted as the return value to the method "SendWithR- 
Box". The object "mCOOPMailer" then enables the ob- 
ject A to restart processing. The object A is now ready - 
to execute processing, and if there is any remaining < : 
processing, the object A restarts the processing. " 
[01 39] According to the above-described processing, x 
the message is delivered from the object A to the object- 5 
B, as indicated by the solid arrow ST1 -6, and it is as if ' 
the object A and the object B were concurrently operat- 
ing, from the point of view of the application programs. 
[0140] Subsequently, when the object A issues the 
method "Receive", as designated by ST1-7, the 
processing is shifted to the object "mCOOPMailer", as 
represented by the single-dot-chain arrow ST1 -8, and 
the processing in response to the method "Receive" is 
executed by the object "mCOOPMailer", as indicated by 
ST1 -9. More specifically, the object "mCOOPMailer" re- 
fers to the data area "RBox" designated by the argument 
"rBoxlD" of the method "Receive". If the result of the 
processing executed by the object B is stored in the data 
area "RBox", the object "mCOOPMailer" delivers the re- 
sult to the object A. If the result of the processing per- 
formed by the object B is not stored in the data area 
"RBox", the object "mCOOPMailer" shifts the state of 
the object A from the execution state to the waiting state. 
[0141] In this example, when the object A has issued 
the method "Receive", the object B has not issued the 
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method "Reply*, and thus, the result of the processing 
executed by the object B is not yet stored in the data 
area "RBox". Accordingly, the object "mCOOPMailer" 
informs the object A, as represented by the single-dot- 
chain arrow ST1 -1 0, that the processing result of the ob- 
ject B is not yet stored in the data area "RBox", and shifts 
the state of the object A from the execution state to the 
waiting state. 

[0142] Thereafter, when the object B issues the meth- 
od "Reply", as indicated by ST1-11, the processing is 
shifted to the object "mCOOPMailer", as designated by 
the single-dot-chain arrow ST1-12, and the processing 
in accordance with the method "Reply" is executed by 
the object "mCOOPMailer", as indicated by ST1-13. 
More specifically, if the object A has already issued the 
method "Receive", the object "mCOOPMailer" delivers 
the result of the processing executed by the object B to 
the object A. If the object A has not yet issued the meth- 
od "Receive", the object "mCOOPMailer" stores the 
processing result of the object B in the data area "RBox". 
[0143] In this example, when the object B has issued 
the method "Reply", the object A has already issued the 
method "Receive". Accordingly, the object "mCOOP- 
Mailer" directly delivers the processing result of the ob- 
ject B to the object A, as represented by the single-dot- 
chain arrow ST1-14, without storing the processing re- 
sult in the data area "RBox". Upon completing the 
processing in a normal condition for the delivery of the 
processing result of the object B to the object A, the ob- 
ject "mCOOPMailer" returns to the object B, as repre- 
sented by the single-dot-chain arrow ST1-15, the value 
indicating that the processing has been correctly com- 
pleted as the return value to the method "Reply". The 
object "mCOOPMailer" then enables the object B to re- 
start processing. The object B is now ready to perform 
processing, and if there is any remaining processing, the 
object B restarts the processing. 
[0144] According to the aforementioned processing, 
the result of the processing performed by the object B 
is delivered to the object A, as indicated by the solid ar- 
row ST1-16, and it is as if the object A and the object B 
were concurrently operating, from the point of view of 
the application programs. 

[0145] In the example shown in Fig. 4, the method 
"Receive" has been issued before the method "Reply- 
is issued. Alternatively, the method "Receive" may be 
issued after the method "Reply" has been issued. In this 
case, the object A is able to immediately receive the re- 
sult of the processing executed by the object B without 
entering the waiting state. 

[01 46] If the object A issues the method "Receive" af- 
ter the object B has issued the method "Reply", the ob- 
ject "mCOOPMailer" executes the following processing. 
The object "mCOOPMailer" stores the processing result 
of the object B in the data area "RBox" upon issuing the 
method "Reply" by the object B. Then, when the object 
A issues the method "Receive", the "mCOOPMailer" im- 
mediately reads the processing result of the object B 



from the data area "RBox" and delivers it to the object A. 
[0147] The result of the processing executed by the 
object B is stored in the data area "RBox". More specif- 
ically, the value indicating that the processing result of 

5 the object B has been returned is set in the attribute 
"ready" of the data area "RBox", and the pointer to the 
area for storing the message to be delivered to the ob- 
ject A as the processing result of the object B, i.e., the 
pointer represented by the argument "resultMsg" of the 

10 method "Reply", is set in the attribute "resultMsg" of the 
data area "RBox", and also, the value indicating the size 
of the message to be delivered to the object A as the 
processing result of the object B, i.e., the value repre- 
sented by the argument "sizeOf ResultMsg" of the meth- 

15 od "Reply", is set in the attribute "sizeOfResultMsg" of 
the data area "RBox". 

[0148] In reading the processing result of the object 
B from the data area "RBox" and delivering it to the ob- 
ject A, the object "mCOOPMailer" first reads the at- 
20 tribute "resultMsg" and the attribute "sizeOfResultMsg" 
of the data area "RBox" from the data area "RBox" which 
is specified by the argument "rBoxlD"of the method "Re- 
ceive", and then reads the data having the size indicated 
by the attribute "sizeOfResultMsg" from the area repre- 
ss sented by the attribute "resultMsg". The read data 
serves as a message to be delivered from the object B 
to the object A. The object "mCOOPMailer" then stores 
the read data in the area indicated by the argument 
"msg" of the method "Receive". The size of the area des- 
30 ignated by the argument "msg" of the method "Receive" 
has been set by the argument "sizeOf Msg" of the meth- 
od "Receive". 

[01 49] According to the above-described processing, 
when the method "Receive" is issued after the method 
35 "Reply" has been issued, as well as when the method 
"Receive" has been issued before the method "Reply" 
is issued, the result of the processing executed by the 
object B is delivered to the object A, and it is as if the 
object A and the object B were concurrently operating. 

40 

2-5-1-2 When an Exception Occurs 

[0150] A description is now given below, with refer- 
ence to Fig. 5, of message passing performed by using 

45 the method "SendWrthRBox" in the mCOOP 
metaSpace when an exception, which interrupts the 
normal processing of the server object, occurs. 
[0151] Fig. 5 illustrates a basic scenario of message 
passing performed by using the method "SendWithR- 

so Box" in the mCOOP metaSpace between an object A 
operating as an application program in the mCOOP 
metaSpace and an object B operating as an application 
program in the mCOOP metaSpace. That is, in this ex- 
ample, the object A is a client object, while the object B 

55 is a server object. It is now assumed in this scenario that 
an exception occurs to the object B after the method 
"Receive" has been issued by the object A, and the ob- 
ject B becomes inoperable. 
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[0152] In this scenario, steps ST2-1, ST2-2, ST2-3, 
ST2-4, ST2-5, ST2-6, ST2-7, ST2-8, ST2-9, and ST2-10 
shown in Fig. 5 are respectively similar to steps ST1-1 , 
ST1-2, ST1-3, ST1-4, ST1-5, ST1-6, ST1-7, ST1-8, 
ST1 -9, and ST1 -1 0 shown in Fig. 4, and an explanation 5 
thereof will thus be omitted. 

[0153] In this scenario, after processing proceeds to 
step ST2-10, when the object A is in the waiting state, 
and when the object B is executing processing, an ex- 
ception, which interrupts normal processing of the ob- 10 
ject B, occurs. 

[0154] When an exception, which interrupts the nor- 
mal processing of the object B, occurs, as indicated by 
ST2-1 1 , the processing is shifted to the object "mCOOP- 
FaultHandler", as represented by the single-dot-chain 15 
arrow ST2-1 2, and predetermined exception handling is 
performed by the object "mCOOPFaultHandler", as in- 
dicated by ST2-1 3. Then, the object "mCOOPFaultHan- 
dler" reports to the object "mCOOPMailer", as indicated 
by the single-dot-chain arrow ST2-1 4, that the object B 20 
has become inoperable due to the occurrence of an ex- 
ception. 

[0155] At this time, the object A is in the waiting state 
after issuing the method "Receive*. Then, the object 
"mCOOP Mailer" returns to the object A, as represented 25 
by the single-dot-chain arrow ST2-1 5, the error code in- 
dicating that the object B has become inoperable due to 
the occurrence of an exception as the return value to 
the method "Receive", and also enables the object A to 
restart processing. The object A is now ready to execute 30 
processing, and if there is any remaining processing, the 
object A restarts the processing. 
[0156] According to the aforementioned processing, 
although the object A is unable to receive a result mes- 
sage, which would be expected to be obtained from the 35 
object B, it receives the error code, as the return value, 
indicating that the object B has become inoperable, and 
is able to resume the execution of processing. The ob- 
ject A then performs the processing in response to the 
occurrence of an error. 40 
[0157] For example, the message indicating that an 
exception has occurred to the object B may be displayed 
on an image display unit, and the user may be instructed 
to reset the processing. Alternatively, an object as an 
alternative to the object B may be downloaded from an 45 
external source via a network, and message passing 
may be performed again. 

[0158] In the scenario shown in Fig. 5, an exception 
occurs to the object B after the method "Receive" has 
been issued by the object A. However, an exception may 50 
occur to the object B before the method "Receive" is is- 
sued by the object A. 

[0159] If an exception has occurred to the object B 
before the method "Receive" is issued by the object A, 
the object "mCOOPMailer" sets in the attribute "status" 55 
of the data area "RBox" the error code indicating that 
the object B has become inoperable due to the occur- 
rence of an exception. 



[0160] Then, when the object A issues the method 
"Receive", the object "mCOOPMailer" reads the error 
code set in the attribute "status" of the data area "RBox", 
and returns the error code to the object A as the return 
value to the method "Receive". The object "mCOOP- 
Mailer" then enables the object A to resume processing. 
In a manner similar to the previous scenario, the object 
A is now ready to perform processing, and if there is any 
remaining processing, the object A restarts the process- 
ing. 

[0161] As described above, the error code indicating 
that the object B has become inoperable due to the oc- 
currence of an exception is set in the attribute "status" 
of the data area "RBox". This prevents the object A from 
wastefully entering the waiting state upon issuing the 
method "Receive", and the object A immediately recog- 
nizes that the object B has become inoperable due to 
the occurrence of an exception. 
[0162] tn the foregoing scenarios, an exception has 
occurred to the object B. In other cases, if a result mes- 
sage cannot be returned to the object A for some rea- 
son, the error code is set in the attribute "status" of the 
data area "RBox". With this arrangement, even if a result 
message cannot be returned to the object A for some 
reason, the error code is returned to the object A so that 
and the object A can be resumed to the operable state 
from the waiting state, which would otherwise cause the ■ 
object A to enter the waiting state and would stop the ' 
system. 

2-5-2 Message Passing Using Delegate() 

[0163] A description is given below, with reference to 
Fig. 6, of message passing performed by using the*" 
method "Delegate" employed when a processing re-«~ 
quest is received and a processing result is returned by 
different server objects. 

[0164] Fig. 6 illustrates a scenario of message pass- & 
ing performed in the mCOOP metaSpace among an ob- $ 
ject A, an object B, and an object C, all of which are 
operating as application programs in the mCOOP 
metaSpace. In this scenario, the reply authorization is 
delegated from the object B to the object C. 
[0165] That is, in this example, the object A is a client 
object, while the object B and the object C are server 
objects. The object B delegates the object C to return 
the processing result to the object A. That is, the object 
B serves as a server object and also as an authorization- 
dele gating object. The object C serves as a server ob- 
ject and also as an authorization-delegated object. 
[0166] When the object A issues the method "Send- 
WithRBox", as indicated by ST3-1, the processing is 
shifted to the object "mCOOPMailer", as represented by 
the single-dot-chain arrow ST3-2, and the processing in 
accordance with the method "SendWithRBox" is exe- 
cuted by the object "mCOOPMailer", as designated by 
ST3-3. 

[0167] The object "mCOOPMailer" first reserves the 
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data area "RBox" for storing the result of the processing 
executed by the server object, and then sets the identi- 
fier for specifying the data area "Thread" corresponding 
to the object A in the attribute "creator" of the data area 
"RBox". 

[0168] Subsequently, the object "mCOOPMailer" re- 
serves the data area "DeliveryBoxA", and stores the 
identifier "rBoxlD" for designating the data area "RBox" 
and the message sent by the method "SendWithRBox" 
therein. 

[0169] The identifier "rBoxlD" for specifying the data 
area "RBox" is stored in the data area "DeliveryBoxA". 
More specifically, the value of the identifier "rBoxlD" for 
designating the data area "RBox" is set in the attribute 
"rBoxlD" of the data area "DeliveryBoxA". 
[0170] The message sent by the method "SendWith- 
RBox" is stored in the data area "DeliveryBoxA". More 
specifically, the value of the argument "msg" of the 
method "SendWithRBox" is set in the attribute "msg" of 
the data area "DeliveryBoxA", and also, the value of the 
argument "sizeOfMsg" of the method "SendWithRBox" 
is set in the attribute "sizeOfMsg" of the data area "De- 
liveryBoxA". 

[0171] Thereafter, the object "mCOOPMailer" deliv- 
ers to the object B, as indicated by the single-dot-chain 
arrow ST3-4, the data stored in the data area "Deliver- 
yBoxA", i.e., the message sent by the method "Send- 
WithRBox", and the identifier "rBoxlD" for designating 
the reserved data area "RBox", thereby starting the 
method of the object B. 

[0172] In this case, only the message is sent to the 
method of the object B, and the identifier "rBoxlD" is 
stored in the data area "Thread" corresponding to the 
object B. In other words, the identifier "rBoxlD" to be de- 
livered to the object B is under the management of the 
operating system, and it is only the message that has 
been sent to the object B, from the point of view of the 
application program. 

[0173] In starting the method of the object B by deliv- 
ering the data stored in the data area "DeliveryBoxA" 
from the object "mCOOPMailer" to the object B, the ob- 
ject B is specified by the argument "destObjlD" of the 
method "SendWithRBox", and the method of the object 
B is designated by the argument "meth" of the method 
■SendWithRBox". 

[0174] Upon completing the aforementioned process- 
ing, as designated by the single-dot-chain arrow ST3-5, 
the object "mCOOPMailer" returns the identifier "rBox- 
lD" for specifying the reserved data area "RBox" to the 
object A, and also returns to the object A the value indi- 
cating that the processing has been correctly complet- 
ed, as the return value to the method "SendWithRBox". 
The object "mCOOPMailer" then enables the object A 
to restart processing. The object A is now ready to ex- 
ecute processing, and if there is any remaining process- 
ing, the object A restarts the processing. 
[01 75] According to the above-described processing, 
the message has been sent from the object A to the ob- 



ject B, as represented by the solid arrow ST3-6, and it 
is as if the object A and the object B were concurrently 
operating, from the point of view of the application pro- 
grams. 

5 [0176] Subsequently, upon issuing the method "Re- 
ceive" by the object A, as indicated by ST3-7, the 
processing is shifted to the object "mCOOPMailer", as 
designated by the single-dot -chain arrow ST3-8, and the 
processing in response to the method "Receive" is ex- 

io ecuted by the object "mCOOPMailer", as designated by 
ST3-9. More specifically, the object "mCOOPMailer" re- 
fers to the data area "RBox" specified by the argument 
"rBoxlD" of the method "Receive". If the result of the 
processing performed by the server object is stored in 

'5 the data area "RBox", the "mCOOPMailer" delivers the 
result to the object A. If the processing result of the serv- 
er object is not stored in the data area "RBox", the object 
"mCOOPMailer" changes the state of the object A from 
the execution state to the waiting state. 

20 [0177] In this example, when the object A has issued 
the method "Receive", the server object has not issued 
the method "Reply". Accordingly, the result of the 
processing executed by the server object is not yet 
stored in the data area "RBox". Thus, the object 

25 "mCOOPMailer" reports to the object A, as indicated by 
the single-dot-chain arrow ST3-10, that the processing 
result of the server object is not stored in the data area 
"RBox", and changes the state of the object A from the 
execution state to the waiting state. 

30 [0178] Thereafter, when the object B issues the meth- 
od "Delegate", as indicated by ST3-11 , the processing 
is shifted to the object "mCOOPMailer", as represented 
by the single-dot-chain arrow ST3-12, and the process- 
ing in accordance with the method "Delegate" is per- 

35 formed by the object "mCOOPMailer", as designated by 
ST3-13. 

[0179] More specifically, the object "mCOOPMailer" 
first reserves the data area "DeliveryBoxA". The object 
"mCOOPMailer" then reads the identifier "rBoxlD" 

40 stored in the data area "Thread" corresponding to the 
object B, and sets the value of the identifier "rBoxlD" in 
the attribute "rBoxlD" of the data area "DeliveryBoxA". 
[0180] Simultaneously, the identifier "rBoxlD" stored 
in the data area "Thread" corresponding to the object B 

45 is erased, thereby depriving the object B of the reply au- 
thorization. That is, the object B loses the reply author- 
ization by issuing the method "Delegate", and delegates 
the reply authorization to the object C. Since the object 
B has lost the reply authorization, it is unable to issue 

so the method "Reply". In other words, the object B has 
issued the method "Delegate" instead of the method 
"Reply". 

[0181] The object "mCOOPMailer" also stores the 
message sent by the method "Delegate" in the data area 
55 "DeliveryBoxA". More specifically, the value of the argu- 
ment "msg" of the method "Delegate" is set in the at- 
tribute "msg" of the data area "DeliveryBoxA", and also, 
the value of the argument "sizeOfMsg" of the method 
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"Delegate" is set in the attribute "sizeOf Msg" of the data 
area "DeliveryBoxA". 

[0182] The object "mCOOPMailer" then delivers to 
the object C, as indicated by the single-dot -chain arrow 
ST3- 14, the data stored in the data area "DeliveryBoxA", s 
i.e., the message sent by the method "Delegate", and 
the identifier "rBoxlD" for specifying the data area 
"RBox", thereby starting the method of the object C. 
[0183] In this case, only the message has been sent 
to the method of the object C, and the identifier "rBoxlD" 
is stored in the data area "Thread" corresponding to the 
object C. In other words, the identifier "rBoxlD" to be de- 
livered to the object C is under the management of the 
operating system, and it is only the message that has 
been sent to the object B, from the point of view of the 
application program. 

[0184] In starting the method of the object C by deliv- 
ering the data stored in the data area "DeliveryBoxA" 
from the object "mCOOPMailer" to the object C, the ob- 
ject C is specified by the argument "destObjlD" of the 
method "Delegate", and the method of the object C is 
designated by the argument "meth" of the method "Del- 
egate". 

[01 85] Upon completing the aforementioned process- 
ing, the object "mCOOPMailer" returns to the object B, 
as indicated by the single-dot-chain arrow ST3-15, the 
value indicating that the processing has been correctly 
completed, as the return value to the method "Dele- 
gate", and then enables the object B to restart process- 
ing. The object B is now ready to execute processing, 
and if there is any remaining processing, the object B 
restarts the processing. 

[0186] According to the aforementioned processing, 
the reply authorization is delegated to the object C from 
the object B, as represented by the solid arrow ST3-16, 
and it is as if the object B and the object C were concur- 
rently operating, from the point of view of the application 
programs. 

[0187] Subsequently, when the object C issues the 
method "Reply", as indicated by ST3-17, the processing 
is shifted to the object "mCOOPMailer", as designated 
by the single-dot-chain arrow ST3-18, and the process- 
ing in response to the method "Reply" is executed by 
the object "mCOOPMailer", as represented by ST3-19. 
More specifically, if the object A has already issued the 
method "Receive", the object "mCOOPMailer" immedi- 
ately delivers the processing result of the object C to the 
object A. If the object A has not yet issued the method 
"Receive", the object "mCOOPMailer" stores the 
processing result of the object C in the data area "RBox". 
[0188] In this example, when the object C has issued 
the method "Reply", the object A has already issued the 
method "Receive". Accordingly, the object "mCOOP- 
Mailer" immediately delivers to the object A, as indicated 
by the single-dot-chain arrow ST3-20, the processing 
result of the object C without storing it in the data area 
"RBox". Upon completing the processing for delivering 
the processing result of the object C to the object A in a 



normal condition, the object "mCOOPMailer" returns to 
the object C, as represented by the single-dot-chain ar- 
row ST3-21 , the value indicating that the processing has 
been correctly completed, as the return value to the 
method "Reply". The object "mCOOPMailer" then ena- 
bles the object C to restart processing. The object C is 
now ready to execute processing, and if there is any re- 
maining processing, the object C restarts the process- 
ing. 

[0189] According to the above-described processing, 
the result of the processing executed by the object C 
has been sent to the object A, as represented by the 
solid arrow ST3-22, and it is as if the object A and the 
object C were concurrently operating, from the point of 
view of the application programs. 
[0190] In the example shown in Fig. 6, the method 
"Receive" has been issued before the method "Reply" 
is issued. Alternatively, the method "Receive" may be 
issued after the method "Reply" has been issued. In this 
case, the object A is able to immediately receive the re- 
sult of the processing executed by the object C without 
entering the waiting state. 

[0191] If the object A issues the method "Receive" af- 
ter the object C has issued the method "Reply", the ob- 
ject "mCOOPMailer" executes the following processing. 
The object "mCOOPMailer" stores the processing result 
of the object C in the data area "RBox" when the method 
"Reply" is issued by the object C. Then, when the object 
A issues the method "Receive", the "mCOOPMailer? im- 
mediately reads the processing result of the object C 
from the data area "RBox" and delivers it to the object A. 
[0192] The result of the processing executed by the 
object C is stored in the data area "RBox". More specif- 
ically, the value indicating that the processing result of 
the object C has been returned is set in the attribute 
"ready" of the data area "RBox", and the pointer to the 
area for storing the message to be delivered to the ob- 
ject A as the processing result of the object C, i.e:, the 
pointer represented by the argument "resultMsg" of the 
method "Reply", is set in the attribute "resultMsg" of the 
data area "RBox". Further, the value indicating the size 
of the message to be delivered to the object A as the 
processing result of the object C, i.e., the value repre- 
sented by the argument "sizeOf ResultMsg" of the meth- 
od "Reply", is set in the attribute "sizeOfResultMsg" of 
the data area "RBox". 

[0193] In reading the processing result of the object 
C from the data area "RBox" and delivering it to the ob- 
ject A, the object "mCOOPMailer" first reads the at- 
tribute "resultMsg" and the attribute "sizeOfResultMsg" 
of the data area "RBox" from the data area "RBox" which 
is specified by the argument "rBoxlD" of the method "Re- 
ceive", and then reads the data having the size indicated 
by the attribute "sizeOfResultMsg" from the area repre- 
sented by the attribute "resultMsg". The read data 
serves as a message to be delivered from the object C 
to the object A. The object "mCOOPMailer" then stores 
the read data in the area indicated by the argument 
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"msg" of the method "Receive". The size of the area des- 
ignated by the argument "msg" of the method ■Receive" 
has been set by the argument "sizeOfMsg" of the meth- 
od "Receive". 

[01 94] According to the above-described processing, 
when the method "Receive" is issued after the method 
"Reply" has been issued, as well as when the method 
"Receive" has been issued before the method "Reply" 
is issued, the result of the processing executed by the 
object C is delivered to the object A, and it is as if the 
object A and the object C were concurrently operating. 
[0195] According to the foregoing description, by in- 
troducing the method "Delegate" as an API used for de- 
scribing an object, even if there are a plurality of server 
objects, the reply authorization can be delegated among 
the server objects. In other words, by introducing the 
method "Delegate", even if there are a plurality of server 
objects, and even if a server object that receives a 
processing request is different from a server object that 
returns a processing result, message passing can be 
suitably performed. 

[0196] Additionally, with the introduction of the meth- 
od "Delegate", in delegating the reply authorization 
among a plurality of server objects, the data area "RBox" 
and the identifier "rBoxlD" for specifying the data area 
■RBox" are transparent to the application programs. 
This enhances the simplicity of the development of ap- 
plication programs. 

[01 97] If the object delegated to possess the reply au- 
thorization by the method "Delegate" (in this example, 
the object C) becomes inoperable due to, for example, 
the occurrence of an error, and is unable to acquire a 
result, exception handling is performed in a manner sim- 
ilar to the scenario shown in Fig. 5. 
[0198] More specifically, in the example shown in Fig. 
6, if the object C delegated to possess the reply author- 
ization by the method "Delegate" becomes inoperable 
during execution due to the occurrence of an error and 
is unable to obtain a result, the processing is shifted to 
the object "mCOOPFaultHandler - , and predetermined 
exception handling is performed by the object "mCOOP- 
FaultHandler". The object "mCOOPFaultHandler" then 
reports to the object ■mCOOP Mailer - that the object C 
has become inoperable due to the occurrence of an er- 
ror. 

[0199] In this case, if the object A has already issued 
the method "Receive" and is in the waiting state, the ob- 
ject "mCOOPMailer" returns to the object A the error 
code indicating that the object C has become inoperable 
due to the occurrence of an error, as the return value to 
the method "Receive", and then enables the object A to 
restart processing. Thus, the object A is ready to exe- 
cute processing, and if there is any remaining process- 
ing, the object A restarts the processing. 
[0200] On the other hand, if an exception has oc- 
curred to the object C before the object A issues the 
method ■Receive", the object "mCOOPMailer - sets in 
the attribute "status" of the data area "RBox" the error 



code indicating that the object C has become inoperable 
due to the occurrence of an error. Then, when the object 
A issues the method "Receive", the object "mCOOP- 
Mailer" reads the error code set in the attribute "status" 

s of the data area "RBox", and returns the error code to 
the object A as the return value to the method "Receive". 
The object ■mCOOPMailer - then enables the object A 
to restart processing. Accordingly, the object A is ready 
to execute processing, and if there is any remaining 

10 processing, the object A restarts the processing. 

[0201] According to the aforementioned processing, 
even if the object C delegated to possess the reply au- 
thorization is unable to return a result message to the 
object A for some reason, the object A can resume the 

15 execution state from the waiting state, which would oth- 
erwise cause the object A to enter the waiting state and 
would stop the system. 

2-5-3 Message Passing Using SendWithContinuation() 

20 

[0202] A description is now given below, with refer- 
ence to Fig. 7, of message passing performed by using 
the method "SendWrthContinuation" in the mDrive 
metaSpace. 

25 [0203] Fig. 7 illustrates a basic scenario of message 
passing performed in the mDrive metaSpace between 
an object A operating as a device driver in the mDrive 
metaSpace and an object B operating as a device driver 
in the mDrive metaSpace. That is, in this example, the 

30 object A is a client object, while the object B is a server 
object. 

[0204] In Fig. 7, the method of the object A that issues 
the method - SendWithContinuation" is indicated by "A:: 
A1 - , while the method of the object B that is started by 

35 the method "SendWrthContinuation" and also issues the 
method "Kick" is represented by "B::B1 ". Moreover, the 
method of the object A started by the method "Kick", i. 
e., the continuation method, is indicated by "A::A2\ 
[0205] When the object A issues the method "Send- 

40 WithContinuation" within the method "A: : A1 ", as indicat- 
ed by ST4-1, the processing is shifted to the object 
■mDrrveMailer", as represented by the single-dot-chain 
arrow ST4-2, and the processing in accordance with the 
method "SendWithContinuation" is performed by the 

45 object "mDrrveMailer", as designated by ST4-3. 

[0206] The object "mDrive Mailer" first reserves the 
data area "Continuation - , and stores the information 
concerning the continuation method therein. More spe- 
cifically, the value of the identifier for specifying the data 

50 area "Thread" corresponding to the object A is set in the 
attribute "creator" of the data area D Continuation", and 
also, the value of the argument "contMeth" of the meth- 
od "SendWithContinuation" is set in the attribute "meth" 
of the data area "Continuation". 

55 [0207] The object "mDrrveMailer" also reserves the 
data area "Delivery BoxB", and stores the identifier "con- 
tlD" for designating the data area "Continuation", and 
the message sent by the method "SendWithContinua- 
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tion" therein. The identifier "contl D" for specifying the 
data area "Continuation" is stored in the data area "De- 
liveryBoxB", and more specifically, the value of the iden- 
tifier "contlD" for specifying the data area "Continuation" 
is set in the attribute "contlD" of the data area "Deliver- 
yBoxB". Moreover, the message sent by the method 
"SendWithContinuation" is stored in the data area "De- 
liveryBoxB", and more specifically, the value of the ar- 
gument "msg" of the method "Send With Continuation" is 
stored in the attribute "msg" of the data area "Delivery- 
BoxB", and also, the value of the argument "sizeOfMsg" 
of the method "SendWithContinuation" is set in the at- 
tribute "sizeOfMsg" of the data area "DeliveryBoxB". 
[0208] Thereafter, the object "mDriveMailer" delivers 
to the object B, as indicated by the single-dot-chain ar- 
row ST4-4, the data stored in the data area "Delivery- 
BoxB", i. e., the message sent by the method "SendWith- 
Continuation", and the identifier "contlD" for specifying 
the data area "Continuation", thereby starting the meth- 
od "B::B1 " of the object B. 

[0209] In starting the method "B::B1 " of the object B 
by delivering the data stored in the data area "Delivery- 
BoxB" from the object "mDriveMailer" to the object B, 
the object B is specified by the argument "destObjlD" of 
the method "SendWithContinuation", and the method 
"B::B1" of the object B is designated by the argument 
"meth" of the method "SendWithContinuation". 
[0210] Upon completing the above-described 
processing, the object "mDriveMailer" returns to the ob- 
ject A, as indicated by the single-dot-chain arrow ST4-5, 
the value indicating that the processing has been cor- 
rectly completed, as the return value to the method 
"SendWithContinuation", and then enables the object A 
to restart processing. Accordingly, the object A is ready 
to execute processing, and if there is any remaining 
processing, the object A restarts the processing. 
[0211] According to the aforementioned processing, 
the message has been sent from the object A to the ob- 
ject B, as indicated by the solid arrow ST4-6, and it is 
as if the object A and the object B were concurrently 
operating, from the point of view of the device drivers. 
[0212] Thereafter, the object B executes the method 
"B::B1 ", and upon completing the processing requested 
by the object A, the object B issues the method "Kick", 
as indicated by ST4-7. Upon issuing the method "Kick", 
the processing is shifted to the object "mDriveMailer", 
as represented by the single<lot-chain arrow ST4-8, 
and the processing in response to the method "Kick" is 
performed by the object "mDriveMailer", as indicated by 
ST4-9. 

[0213] More specifically, the object "mDriveMailer" 
first specifies the data area "Continuation" based on the 
argument "contlD" of the method "Kick", and then reads 
the information stored in the data area "Continuation". 
[0214] As the attribute "creator", the value of the iden- 
tifier designating the data area "Thread" corresponding 
to the object A is stored in the data area "Continuation". 
According to the identifier, the object "mDriveMailer" 
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designates the object A as the object to be started in 
response to the method "Kick". The value of the argu- 
ment "contMeth" of the method "SendWithContinua- 
tion", i.e., the value specifying the continuation method 

5 "A::A2", is set in the attribute "meth" of the data area 
"Continuation". According to the argument "contMeth", 
the object "mDriveMailer" specifies the method "A::A2" 
as the continuation method to be started in response to 
the method "Kick". 

10 [0215] The object "mDriveMailer" then starts, as des- 
ignated by the single-dot-chain arrow ST4-1 0, the meth- 
od of the object specified by the information stored in 
the data area "Continuation", i.e., the method "A::A2" of 
the object A, as the continuation method. In starting the 

'5 continuation method "A::A2", the message to be deliv- 
ered to the continuation method "A::A2" is designated 
by the arguments "msg" and "sizeOfMsg" of the method 
"Kick". 

[0216] Upon correctly completing the start of the con- 
20 tinuation method "A::A2" of the object A, the object 
"mDriveMailer" returns to the object B, as indicated by 
the single-dot-chain arrow ST4-11, the value indicating 
that the processing of the method "Kick" has been cor- 
rectly completed, as the return value to the method 
25 "Kick". The object "mDriveMailer" then enables the ob- 
ject B to restart processing. Accordingly, the object B is 
readyto execute processing, and if there is any remain- 
ing processing, the object B restarts the processings 
[0217] According to the aforementioned processing, 
30 the continuation method "A::A2" of the object A is started 
by the object B, as designated by the solid arrow 
ST4-1 2, and it is as if the object A and the object B were 
concurrently operating, from the point of view of the de- 
vice drivers. 

35 

2-5-4 Message Passing between Different metaSpaces 

[0218] A description is given below, with referenced) 
Fig. 8, of message passing performed by using the 
40 method "Delegate" between the mCOOP metaSpace 
and the mDrive metaSpace. 

[0219] As a scenario of message passing performed 
between different metaSpaces, Fig. 8 illustrates mes- 
sage passing among an object A operating as an appli- 
es cation program in the mCOOP metaSpace, an object B 
operating as an application program in the mCOOP 
metaSpace, and an object C operating as a device driv- 
er in the mDrive metaSpace. In this scenario, the object 
B delegates the reply authorization to the object C. 
so [0220] That is, in this example, the object A is a client 
object, while the object B and the object C are server 
objects. The object B delegates the object C to return 
the processing result to the object A. That is, the object 
B serves as a server object and also as an authorization- 
's delegating object. The object C serves as a server ob- 
ject and also as an authorization-delegated object. ' 
[0221] In this scenario, steps ST5-1, ST5-2, ST5-3, 
ST5-4, ST5-5, ST5-6, ST5-7, ST5-8, ST5-9, and ST5-10 



EP 0 940 750 A2 



17 



33 



EP 0 940 750 A2 



shown in Fig. 8 are respectively similar to ST3-1 , ST3-2, 
ST3-3, ST3-4, ST3-5, ST3-6, ST3-7, ST3-8, ST3-9, and 
ST3-10 shown in Fig. 2, and an explanation thereof will 
thus be omitted. 

[0222] In this scenario, after processing proceeds to 
step ST5-10, when the object A is in the waiting state, 
and when the object B is executing processing, the ob- 
ject B issues the method "Delegate" for delegating the 
reply authorization. 

[0223] When the object B issues the method "Dele- 
gate", as indicated by ST5-11 , the processing is shifted 
to the object "mCOOPMailer", as represented by the 
single-dot-chain arrow ST5-12, and the processing in 
response to the method "Delegate" is executed by the 
object "mCOOPMailer", as designated by ST5-13. 
[0224] In this case, the object "mCOOPMailer" deter- 
mines whether the authorization -delegated object is an 
object operating in the mCOOP metaSpace. If it is found 
that the authorization -delegated object is an object op- 
erating in the mCOOP metaSpace, the processing pro- 
ceeds in accordance with the scenario shown in Fig. 6. 
In this example, however, the authorization -de legated 
object is not an object operating in the mCOOP 
metaSpace, but is the object C operating in the mDrive 
metaSpace. Accordingly, the processing is shifted from 
the object "mCOOPMailer" to the object "mDriveMailer", 
as represented by the single-dot-chain arrow ST5-14. 
[0225] A shift of the processing from the object 
"mCOOPMailer" to the object "mDriveMailer" is per- 
formed via a micro-kernel. More specifically, the object 
"mCOOPMailer" first determines based on the argu- 
ment "destObjlD" of the method "Delegate" that the 
metaSpace in which the authorization -de legated object 
is operating is an mDrive metaSpace. Subsequently, by 
using the function of the micro-kernel, the object 
"mCOOPMailer" requests the object "mDriveMailer", 
which is a metaObject for performing message passing 
between the objects operating in the mDrive 
metaSpace, to execute the required processing. Thus, 
the processing is shifted from the object "mCOOPMail- 
er" to the object "mDriveMailer*. 

[0226] In this manner, after the processing is shifted 
from the object "mCOOPMailer" to the object "mDrive- 
Mailer", the processing in accordance with the method 
■Delegate" is executed by the object "mDriveMailer", as 
represented by ST5-15. 

[0227] More specifically, the object "mDriveMailer" 
first reserves the data area "DeliveryBoxB". The object 
"mDriveMailer" then reads the identifier "rBoxlD" stored 
in the data area "Thread" corresponding to the object B 
and sets the identifier "rBoxlD" in the attribute "contID" 
of the data area "DeliveryBoxB". 
[0228] Simultaneously, the identifier "rBoxlD" stored 
in the data area "Thread" corresponding to the object B 
is erased, thereby depriving the object B of the reply au- 
thorization. That is, the object B loses the reply author- 
ization by issuing the method "Delegate", and delegates 
the reply authorization to the object C. Since the object 
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B has lost the reply authorization, it is unable to issue 
the method "Reply". In other words, the object B has 
issued the method "Delegate" instead of the method 
"Reply". 

5 [0229] The object "mDriveMailer" also stores the 
message sent by the method "Delegate" in the data area 
"DeliveryBoxB". More specifically, the value of the argu- 
ment "msg" of the method "Delegate" is set in the at- 
tribute "msg" of the data area "DeliveryBoxB", and also, 

io the value of the argument "sizeOfMsg" of the method 
"Delegate" is set in the attribute "sizeOf Msg" of the data 
area "DeliveryBoxB". 

[0230] The object "mDriveMailer" then delivers to the 
object C, as indicated by the single-dot-chain arrow 

is ST5-1 6, the data stored in the data area "DeliveryBoxB", 
i.e., the message sent by the method "Delegate", and 
the identifier "rBoxlD" for specifying the data area 
"RBox", thereby starting the method of the object C. 
[0231] In this case, only the message has been sent 

20 to the method of the object C, and the identifier "rBoxlD" 
is stored in the data area "Thread" corresponding to the 
object C. In other words, the identifier "rBoxlD" to be de- 
livered to the object C is under the management of the 
operating system, and it is only the message that has 

25 been sent to the object C, from the point of view of the 
application program. 

[0232] In starting the method of the object C by deliv- 
ering the data stored in the data area ■DeliveryBoxB" 
from the object "mDriveMailer" to the object C, the object 

30 c is specified by the argument "destObjl D" of the meth- 
od "Delegate", and the method of the object C is desig- 
nated by the argument "meth" of the method "Delegate". 
[0233] Upon completing the aforementioned process- 
ing, the object "mDriveMailer" returns to the object B via 

3S the object "mCOOPMailer", as indicated by the single- 
dot-chain arrows ST5-17 and ST5-18, the value indicat- 
ing that the processing has been correctly completed, 
as the return value to the method "Delegate", and then 
enables the object B to restart processing. The object B 

40 js now ready to execute processing, and if there is any 
remaining processing, the object B restarts the process- 
ing. 

[0234] According to the aforementioned processing, 
the reply authorization has been delegated form the ob- 
45 ject B to the object C, as indicated by the solid arrow 
ST5-1 9, and it is as if the object B and the object C were 
concurrently operating, from the point of view of the ap- 
plication programs. 

[0235] Thereafter, upon completing the processing 
so requested by the object A, the object C issues the meth- 
od "Kick", as designated by ST5-20. Upon issuing the 
method "Kick", the processing is shifted to the object 
"mDriveMailer", as represented by the single-dot-chain 
arrow ST5-21, and the processing in response to the 
55 method "Kick" is executed by the object "mDriveMailer", 
as indicated by ST5-22. 

[0236] Simultaneously, the object "mDriveMailer" 
reads the information stored in the data area "Thread" 
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corresponding to the object C. If the identifier "contlD" 
specifying the data area "Continuation" is stored in the 
data area "Thread", the processing for starting the con- 
tinuation method proceeds in accordance with the sce- 
nario shown in Fig. 7. In this example, however, not the 
identifier "contlD" designating the data area "Continua- 
tion", but the identifier "rBoxlD" specifying the data area 
"RBox" is stored in the data area "Thread". 
[0237] Since the identifier "rBoxlD" specifying the da- 
ta area "RBox" is stored in the data area "Thread", as 
noted above, the processing is shifted from the object 
"mD rive Mailer" to the object "mCOOPMailer", as indi- 
cated by the single-dot-chain arrow ST5-23, rather than 
starting the continuation method by the object "mDrive- 
Mailer". 

[0238] A shift of the processing from the object 
"mDriveMailer" to the object "mCOOPMailer" is per- 
formed via the micro-kernel. More specifically, the object 
"mDriveMailer" first checks whether the identifier stored 
in the data area "Thread" corresponding to the object C 
is the identifier "contlD" for specifying the data area 
■Continuation" used in the m Drive metaSpace. In this 
example, it is determined that the identifier stored in the 
data area "Thread" corresponding to the object C is not 
the identifier "contlD" designating the data area "Con- 
tinuation". 

[0239] The information for determining the 
metaSpace in which the object to be communicated by 
message passing is operating is also stored in the data 
area "Thread" corresponding to each object. The iden- 
tifier stored in the data area "Thread" corresponding to 
the object C is not the identifier "contlD" for specifying 
the data area "Continuation". Thus, the data area 
"Thread" corresponding to the object C is further exam- 
ined to determine the metaSpace in which the object to 
be communicated by message passing is operating. As 
a result, it is determined in this example that the 
metaSpace in which the object to be communicated by 
message passing is operating is a mCOOP metaSpace. 
[0240] Then, by using the function of the micro-kernel, 
the object "mDriveMailer" requests the object "mCOOP- 
Mailer", which is a metaObject for performing message 
passing between the objects operating in the mCOOP 
metaSpace, to execute the required processing. Thus, 
the processing is shifted from the object "mDriveMailer" 
to the object "mCOOPMailer". 

[0241] In this manner, after the processing has been 
shifted from the object "mDriveMailer" to the object 
"mCOOPMailer", the processing in accordance with the 
method "Kick" is executed by the object "mCOOPMail- 
er", as indicated by ST5-24. 

[0242] More specifically, if the object A has already 
issued the method "Receive", the object "mCOOPMail- 
er" delivers the result of the processing executed by the 
object C to the object A. If the object A has not yet issued 
the method "Receive", the object "mCOOPMailer" 
stores the processing result of the object C in the data 
area "RBox". 



[0243] In this example, when the object C issues the 
method "Kick", the object A has already issued the 
method "Receive". Accordingly, the object "mCOOP- 
Mailer" immediately delivers to the object A, as desig- 

5 nated by the single-dot-chain arrow ST5-25, the 
processing result of the object C without storing it in the 
data area "RBox". Upon correctly completing the 
processing for the delivery of the processing result of 
the object C to the object A, the object "mCOOPMailer" 

10 returns to the object C via the object "mDriveMailer", as 
represented by the single-dot-chain arrows ST5-26 and 
ST5-27, the value indicating that the processing has 
been correctly completed, as the return value to the 
method "Kick". The "mCOOPMailer" then enables the 

is object C to restart processing. The object C is now ready 
to execute processing, and if there is any remaining 
processing, the object C restarts the processing. 
[0244] According to the above-described processing, 
the result of the processing executed by the object C 

20 has been sent to the object A, as indicated by the solid 
arrow ST5-28, and it is as if the object A and the object 
C were concurrently operating, from the point of view of 
the application programs. 

[0245] In the example shown in Fig. 8, the method 

25 "Receive" has been issued before the method "Kick" is 
issued. Alternatively, the method "Receive" may be is- 
sued after the method "Kick" has been issued. In this 
case, the object A is able to immediately receive the re- 
sult of the processing executed by the object C without 

30 entering the waiting state. • • 

[0246] If the object A issues the method "Receive" af- 
ter the object C has issued the method "Kick", the object 
"mCOOPMailer" executes the following processing. 
The object "mCOOPMailer" stores the processing result * 

35 of the object C in the data area "RBox" when the method 
"Kick" is issued by the object C. Then, when the object 
A issues the method "Receive", the "mCOOPMailer" im- 
mediately reads the processing result of the object C 
from the data area "RBox" and delivers it to the object A. 

40 [024*7] The result of the processing executed by the 
object C is stored in the data area "RBox". More specif- 
ically, the value indicating that the processing result of 
the object C has been returned is set in the attribute 
"ready" of the data area "RBox", and the pointer to the 

45 area for storing the message to be delivered to the ob- 
ject A as the processing result of the object C, i.e., the 
pointer represented by the argument "msg" of the meth- 
od "Kick", is set in the attribute "resultMsg" of the data 
area "RBox". Moreover, the value indicating the size of 

50 the message to be delivered to the object A as the 
processing result of the object C, i.e., the value repre- 
sented by the argument "sizeOfMsg" of the method 
"Kick", is set in the attribute "sizeOfResultMsg" of the 
data area "RBox". 

55 [0248] In reading the processing result of the object 
C from the data area "RBox" and delivering it to the ob- 
ject A, the object "mCOOPMailer" first reads the at- 
tribute "resultMsg" and the attribute "sizeOfResultMsg" 
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of the data area "RBox" from the data area "RBox" which 
is specified by the argument "rBoxl D" of the method "Re- 
ceive", and then reads the data having the size indicated 
by the attribute "sizeOfResultMsg" from the area repre- 
sented by the attribute "resultMsg". The read data 
serves as a message to be delivered from the object C 
to the object A. The object "mCOOPMailer" then stores 
the read data in the area indicated by the argument 
"msg" of the method "Receive". The size of the area des- 
ignated by the argument "msg" of the method "Receive" 
has been set by the argument "sizeOf Msg" of the meth- 
od "Receive". 

[0249] According to the above-described processing, 
when the method "Receive" is issued after the method 
"Kick" has been issued, as well as when the method 
"Receive" has been issued before the method "Kick" is 
issued, the result of the processing executed by the ob- 
ject C is delivered to the object A, and it is as if the object 
A and the object C were concurrently operating. 
[0250] If the object delegated to possess the reply au- 
thorization by the method "Delegate" (in this example, 
the object C) becomes inoperable due to, for example, 
the occurrence of an error, and is unable to acquire a 
result, exception handling is performed in a manner sub- 
stantially similar to the scenario shown in Fig. 5. 
[0251] More specifically, in the example shown in Fig. 
8, if the object C delegated to possess the reply author- 
ization by the method "Delegate" becomes inoperable 
during execution due to, for example, the occurrence of 
an error and is unable to obtain a result, the processing 
is shifted to the object °m Drive Fau ft Handler", and pre- 
determined exception handling is performed by the ob- 
ject "mDriveFaultHandler". The object "mDriveFault- 
Handler" then reports to the object "mCOOPMailer" via 
the object "mDriveMailer" that the object C has become 
inoperable due to the occurrence of an error. 
[0252] In this case, if the object A has already issued 
the method "Receive" and is in the waiting state, the ob- 
ject "mCOOPMailer" returns to the object A the error 
code indicating that the object C has become inoperable 
due to the occurrence of an error, as the return value to 
the method "Receive", and then enables the object A to 
restart processing. Thus, the object A is ready to exe- 
cute processing, and if there is any remaining process- 
ing, the object A restarts the processing. 
[0253] On the other hand, if an exception has oc- 
curred to the object C before the object A issues the 
method "Receive", the object "mCOOPMailer" sets in 
the attribute "status" of the data area "RBox" the error 
code indicating that the object C has become inoperable 
due to the occurrence of an error. Then, when the object 
A issues the method "Receive", the object "mCOOP- 
Mailer" reads the error code set in the attribute "status" 
of the data area "RBox", and returns the error code to 
the object A as the return value to the method "Receive". 
The object "mCOOPMailer" then enables the object A 
to restart processing. Accordingly, the object A is ready 
to execute processing, and if there is any remaining 



processing, the object A restarts the processing. 
[0254] According to the aforementioned processing, 
even if the object C delegated to possess the reply au- 
thorization is unable to return a result message to the 

5 object A for some reason, the object A can be resumed 
to the execution state from the waiting state, which 
would otherwise cause the object A to enter the waiting 
state and would stop the system. 
[0255] As is seen from the foregoing detailed descrip- 

10 tion, the present invention offers the following advantag- 
es. 

[0256] When a message is sent from a client object 
to a server object, a data area is reserved. If processing 
executed by the server object is not correctly completed, 

15 the data indicating the status of the server object is de- 
livered to the client object via the above data area. 
[0257] Consequently, according to the present inven- 
tion, even if the client object enters the waiting state due 
to some problem while future-based message passing 

20 js being performed, the status of the server object can 
be informed to the client object without needing to exe- 
cute time-out processing, thereby enabling the client ob- 
ject to exit from the waiting state. 
[0258] Additionally, in the present invention, if the 

25 processing executed by the server object is not correctly 
completed, the data indicating the status of the server 
object is delivered to the client object via the above-de- 
scribed data area, which would otherwise waste time, 
as in the case in which time-out processing is executed. 

30 Thus, the client object can speedily exit from the waiting 
state. 

[0259] The data indicating the status of the server ob- 
ject is delivered to the cl ient object when the processing 
executed by the server object is not correctly completed, 
35 thereby making it possible to specify the cause for the 
occurrence of a waiting state. Accordingly, the process- 
ing can be performed to suitably overcome the cause, 
thereby preventing the occurrence of another waiting 
state for the same reason. 

40 

Claims 

1. A data processing method in which a message is 
45 sent from a client object to a server object, said 
server object executing processing in response to 
a request by the message and returning a result of 
the processing to said client object, said method 
comprising the steps of: 

50 

reserving an area for storing result data indicat- 
ing the result of the processing executed by 
said server object, and an area for storing sta- 
tus data indicating a status of said server ob- 
55 ject, upon sending the message from said client 

object to said server object; 
storing the result data in the data area when the 
processing executed by said server object has 
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been correctly completed, or storing the status 
data in the data area when the processing ex- 
ecuted by said server object has not been cor- 
rectly completed; and 

receiving the result data by reading the data 
stored in the data area by said client object 
when the processing executed by said server 
object has been correctly completed, or receiv- 
ing the status data by reading the data stored 
in the data area by said client object when the 
processing executed by said server object has 
not been correctly completed. 

2. A data processing method according to claim 1 , fur- 
ther comprising the steps of: 

controlling said client object to continue 
processing after said client object has sent the 
message to said server object, and to read the 
data stored in the data area when said client 
object requires the result of the processing ex- 
ecuted by said server object; and 
controlling said client object to enter a waiting 
state when neither the result data nor the status 
data is stored in the data area upon reading the 
data stored in the data area, and controlling 
said client object to remain in the waiting state 
until the result data or the status data is stored 
in the data area. 

3. A recording medium on which an operating system 
is recorded, said operating system comprising mes- 
sage-sending means, as an application program in- 
terface for describing an object, for sending to an- 
other object a message that requests said object to 
perform processing and to return a result of the 
processing; said operating system, in use, perform- 
ing the steps of: 

sending a message from a client object to a 
server object in accordance with said message- 
sending means, and reserving a data area in- 
cluding a portion for storing result data indicat- 
ing a result of processing executed by said 
server object and a portion for storing status da- 
ta indicating a status of said server object; and 
storing the result data in the data area when the 
processing executed by said server object has 
been correctly completed, or storing the status 
data in the data area when the processing ex- 
ecuted by said server object has not been cor- 
rectly completed. 
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A recording medium according to claim 4, wherein 
said operating system controls said client object to 
enter a waiting state when neither the result data 
nor the status data is stored in the data area upon 
reading the data stored in the data area, by said cli- 
ent object by using said data reading means, and 
controls said client object to remain in the waiting 
state until the result data or the status data is stored 
in the data area. 

A data processing apparatus comprising a record- 
ing medium on which an operating system is record- 
ed, said operating system comprising message- 
sending means, as an application program inter- 
face for describing an object, for sending to another 
object a message that requests said object to per- 
form processing and to return a result of the 
processing, said operating system, in use. perform- 
ing the steps of: 

sending a message from a client object to a 
server object in accordance with said message- 
sending means, and reserving a data area in- 
cluding a portion for storing result data indicat- 
ing a result of processing executed by said 
server object and a portion for storing status da- a 
ta indicating a status of said server object; and ■ 
storing the result data in the data area when the 
processing executed by said server object has * 
been correctly completed, or storing the status 
data in the data area when the processing ex- 
ecuted by said server object has not been cor- 
rectly completed. 

A data processing apparatus according to claim 6, .*. 
wherein said operating system comprises data'-:;, 
reading means for reading the data stored in the da- 'i 
ta area, as an application program interface used % 
for describing an object. 

A data processing apparatus according to claim 7, 
wherein said operating system controls said client 
object to enter a waiting state when neither the re- 
sult data nor the status data is stored in the data 
area upon reading the data stored in the data area, 
by said client object by using said data reading 
means, and controls said client object to remain in 
the waiting state until the result data or the status 
data is stored in the data area. 



4. A recording medium according to claim 3, wherein 
said operating system comprises data reading ss 
means for reading the data stored in the data area, 
as an application program interface used for de- 
scribing an object. 
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